home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 10450 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: casbah.acns.nwu.edu!muzaffar
  2. From: muzaffar@casbah.acns.nwu.edu (Usman Muzaffar)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Segmentation Fault ???
  5. Date: 18 Mar 1996 00:09:12 GMT
  6. Organization: Northwestern University, Evanston IL
  7. Message-ID: <4ii9j8$n7d@news.acns.nwu.edu>
  8. References: <4hsa7i$en3@wraith.its.uow.edu.au> <4huis1$cm2@ccshst05.cs.uoguelph.ca> <4hv75jINNpss@keats.ugrad.cs.ubc.ca> <4hvaq3$n8f@ccshst05.cs.uoguelph.ca>
  9. NNTP-Posting-Host: casbah.acns.nwu.edu
  10.  
  11. In article <4hvaq3$n8f@ccshst05.cs.uoguelph.ca>,
  12. Toby K Hay <thay@uoguelph.ca> wrote:
  13. >Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
  14. >
  15. >: It means that you are making errors in your code that the Turbo C environment
  16. >: doesn't catch. The bus error is likely caused by invoking
  17. >: implementation-specific behavior that is in contravention to standard C:
  18. >: converting a pointer to one that has a stricter alignment. On many of the
  19. >: processors used in UNIX workstations, the address of a long word has to be
  20. >: divisible by four. On a 68000 processor, the address of a 16-bit word has to be
  21. >: divisible by two.
  22. >: If you fail to meet these alignment restrictions, the hardware will trigger an
  23. >: exception, and the UNIX kernel will send a SIGBUS signal to your program.
  24. >
  25. >Would lint catch this for me, or will I have to learn about alignment 
  26. >restrictions to run my program?
  27. >
  28. >: A ``segmentation fault'', (SIGSEGV signal), on the other hand, is caused by
  29. >: accessing illegal memory, such as dereferencing a null pointer, reaching past
  30. >: the limits of your malloc heap or stack and so forth.
  31. >
  32. >From three replies I received via E-mail I understand that accessing 
  33. >illegal memory is almost certainly caused by using uninitialized pointers 
  34. >- something I will check my code for again.  But what determines the 
  35. >limits of my malloc heap, stack, and so forth?  Can I request more memory 
  36. >for these at the command line when I start the program?
  37. >Toby Hay    thay@uoguelph.ca
  38.  
  39. Not usually, I don't think. But it is always good practice to check if
  40. the memory you just requested with a malloc() or calloc() or whatever
  41. actually was returned to you, or if the pointer is NULL. In the second
  42. case, you either have a memory leak, or you are genuinely running out
  43. of memory.
  44.  
  45.